1. Technical Field
The subject matter discussed herein relates to back-up processes and controls for a computer network of database servers.
2. Description of the Related Art
Some organizations employ large networks of databases in order to store, manage, and process significant amounts of information. For example, utility companies may have incredibly large amounts of information pertaining to customers, utility usage by customer, utility rates, billing information, collection information, etc. Similarly, credit card issuers and other financial companies may collect and store significant amounts of information regarding their customers including transactions, investments, portfolio holdings, trades, billing information, statement information, payment information, etc. All of this information may be distributed in databases on separate computers located throughout the organization. For example, accounts payable may be stored in a database on a computer associated with the accounts payable department while utility usage information is stored in a database on multiple computers geographically located within different regional services areas. In some organizations there may be hundreds of separate computers hosting thousands of databases for storing critical information.
All of this information needs to periodically be backed-up in order to avoid a catastrophe should one of the individual computers managing a particular database fail. In large organizations, the distributed databases are often located on data servers that are connected within the organization via a network. Common relational database networks of this type often operate using structured query language (SQL) and the computers in the network are called SQL (“sequel”) servers. The network often also includes a network back-up server that provides back-up data storage for all of the database servers on the network. The back-up server is often in the form of a large tape library with robotic arms that select and install back-up tapes from the library specific to each database server when a scheduled back-up for that database occurs.
Sometimes, however, these scheduled back-up attempts fail for a variety of reasons, for example, a faulty network connection, lack of sufficient bandwidth, a tape failure, a software bug, a power failure, or any of a number of other reasons. When dealing with extremely large database networks, these failures may be regular occurrences, but may be ultimately corrected when the next scheduled back-up occurs without error. However, it is difficult to determine whether a back-up failure is an isolated or one-time error or whether there is a more significant problem that needs addressing.
Current network back-up systems have the ability to provide some forms of error notification to a live administrator, often in the form of an electronic mail (“e-mail”) message. However, this information is generally limited and merely indicates a failure occurrence without an indication of why, what kind of back-up operation was attempted, or whether a later scheduled back-up attempt is successful. In the case of database servers hosting multiple databases, there is also no ability to implement a corrective back-up restricted to only the database that failed; current solutions require back-up of all databases on a particular server. A non-scheduled, fall back-up all databases on a database server could be incredibly time consuming and waste network resources. Furthermore, in very large database networks, the number of failure messages that may be generated can reach into the hundreds on a daily basis. This is an overwhelming number of potential errors for a live administrator to effectively review and investigate.
The information included in this Background section of the specification, including any references cited herein and any description or discussion thereof, is included for technical reference purposes only and is not to be regarded subject matter by which the scope of the invention is to be bound.